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Preface 


This  report  describes  the  design  of  a  proof-of-concept  profiler  systems 
for  measuring  meteorological  corrections  for  Army  artillery. 
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Executive  Summary 

General 

V* 

Accurate  artillery  first  round  fire-for-effect  requires  correction  for  the 
effects  of  the  atmosphere  on  the  trajectory.  Wind,  density,  and  speed- 

»  of-sound  effects  (mediated  by  virtual  temperature  effects),  if  not 

properly  compensated,  produce  very  large  errors.  The  traditional 
method  for  computing  the  corrections  is  based  on  measurement  of  the 
atmosphere  using  a  balloon-borne  rawindsonde.  Unfortunately, 
rawindsonde  launches  are  expensive  and  time  consuming.  Current 
systems  can  only  track  one  balloon  at  a  time;  therefore,  by  necessity, 
balloon  launches  are  widely  spaced  in  time.  The  necessity  of  a 
hydrogen  generator  or  a  supply  of  helium  adds  logistical  complexity. 
Finally,  the  rawindsonde  can  only  make  measurements  along  the 
trajectory  of  the  balloon,  which  goes  where  the  wind  blows  it. 

The  Met  Measuring  Set  Profiler  (MMS-P)  is  intended  to  supplement 
the  balloon-borne  rawindsonde  with  remote  sensing  techniques.  The 
single  rawindsonde  profile  through  the  atmosphere  will  be  replaced 
by  a  meteorological  model  product  which  provides  a  4-dimensional 
(3  dimensions  of  space  plus  time)  representation  of  the  atmospheric 
state  in  the  battle  zone.  These  changes  not  only  provide  more  timely 
meteorology  but  also  provide  meteorology  in  the  launch  area,  at 
apogee,  and  in  the  target  area. 

Development  of  a  proof-of-concept  system  embodying  extensive 
previous  research  was  begun  in  FY  1997.  Because  the  system  was 
based  on  integrating  several  existing  sensor  systems  with  the  current 
Met  Measuring  Set  (MMS),  and  each  component  used  a  different 
operating  system  and  proprietary  software,  the  resulting  system 
integration  task  presented  many  challenges.  The  adopted  system 
concept  linked  major  components  by  Ethernet  and  used  JAVA  to 
interface  with  individual  components  and  manage  overall  system 
functions. 

In  January  of  1998,  a  full-scale  demonstration  of  system  and  sensor 
connectivity  and  communication  was  conducted.  The  present  report 
describes  the  system  configuration  at  the  time  of  the  demonstration 
and  discusses  the  lessons  learned  from  that  demonstration.  A 
principal  result  of  the  demonstration  was  to  prove  the  feasibility  of 
integrating  the  hardware  using  the  JAVA-based  system  concept  and 
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system  integration  software.  It  revealed,  however,  several 
opportunities  for  simplifying,  streamlining,  and  otherwise  improving 
the  efficiency  and  increasing  the  capability  of  the  system. 

Conclusions 

The  JAVA-based  system  integration  scheme  proved  its  ability  to 
integrate  a  diverse  group  of  sensors  operated  by  computers  using 
several  different  operating  systems.  Opportunities  for  optimization 
remain. 


Recommendations 

With  the  basic  soundness  of  the  system  demonstrated,  future  efforts 
should  concentrate  on  improving  the  system  speed,  simplicity,  and 
efficiency  within  the  overall  conceptual  scheme.  Decreasing  the 
physical  volume  of  the  processing  hardware  should  remain  a  priority. 


1.0  Introduction 


1.1  Background 

Accurate  artillery  first  round  fire-for-effect  requires  correction  for  the 
effects  of  the  atmosphere  on  the  trajectory.  An  artillery  shell  is 
subjected  to  drag  forces  during  its  flight  that  depend  on  wind, 
density,  and  virtual  temperature.  These  effects,  if  not  properly 
compensated,  produce  very  large  errors.  The  traditional  method  for 
computing  the  corrections  is  based  on  measurement  of  the 
atmosphere  using  a  balloon-borne  rawindsonde.  The  current  U.S. 
Army  system  for  providing  this  information  is  the  Met  Measuring  Set 
(MMS)  AN/TMQ-41. 

The  MMS  consists  of  a  system  for: 

•  launching  and  tracking  balloons, 

•  gathering  the  resulting  sounding  data,  and 

•  communicating  it  to  the  weapon  systems. 

Unfortunately,  this  system  has  several  disadvantages.  The 
consumables  required  by  rawindsonde  launches  are  expensive  and 
the  operation  is  time  consuming.  Current  systems  can  only  track  one 
balloon  at  a  time;  therefore,  by  necessity,  launches  are  widely  spaced 
in  time.  The  balloons  need  a  supply  of  lighter-than-air  gas  for  lift, 
which  requires  a  hydrogen  generator  or  a  supply  of  pressurized 
helium  cylinders.  These  constitute  a  hazard  and  add  logistical 
complexity.  Finally,  the  rawindsonde  can  only  make  measurements 
along  the  trajectory  of  the  balloon,  which  goes  where  the  wind 
blows  it. 


1.2  The  MMS-Profiler  Proof-of-Concept  System 

The  U.S.  Army  Research  Laboratory  (ARL),  Computational 
Information  Sciences  Directorate  (CISD),  Battlefield  Environment 
Division  (BED)  has  designed  and  built  a  proof-of-concept  system 
replacement  for  the  MMS,  which  is  called  the  MMS-Profiler  (MMS-P). 
While  this  design  was  conceived  as  a  product  improvement  to  the 
MMS,  it  incorporates  far-reaching  changes  in  design  and  capability. 
These  stem  from  new  methods  for  gathering,  interpreting  and 
analyzing  data,  especially  remotely  sensed  data.  [1,2,3] 
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The  proof-of-concept  system  MMS-P  has  been  in  development  for 
some  time,  starting  with  experiments  in  remote  sensing  technology 
that  began  in  1984  at  the  U.S.  Army  Atmospheric  Sciences  Laboratory 
(the  predecessor  of  the  current  CISD,  BED).  The  proof-of-concept 
evolved  from  isolated  instruments  to  a  fieldable  collection  of  trailers 
until  the  technology  was  deemed  ripe  for  design  of  an  operational 
proof-of-concept  system  in  early  FY  1997.  An  initial  tabletop 
demonstration  of  the  integrated  system  was  conducted  in 
January  1998. 

The  MMS-P  proof-of-concept  system  is  capable  of  producing  a 
vertical  profile  of  wind  speed  and  direction,  temperature,  relative 
humidity,  and  atmospheric  pressure  from  the  surface  to  20  km.  The 
system  includes  sensors,  programs  for  data  fusion,  and  a  meso-scale 
meteorological  model.  The  sensor  suite  consists  of  a  Semi-automatic 
Meteorological  Station  (SMS),  wind  radar,  temperature,  and  moisture 
sensing  radiometric  profiler,  facilities  for  launching  and  tracking 
rawindsondes,  and  a  satellite  receiver.  Several  computers, 
interconnected  by  Ethernet,  manage  data  assimilation;  data  fusion; 
and  communication  with  the  tactical  network  via  the  Single  Channel 
Ground  and  Airborne  Radio  System  (SINCGARS).  Another 
connected  computer  runs  a  meso-scale  meteorological  model,  the 
Battlescale  Forecast  Model  (BFM).  The  BFM  assimilates  the  MMS-P 
data.  Navy  Operational  Global  Atmospheric  Prediction  System 
(NOGAPS)  model  gridded  data  from  the  Air  Force  Weather  Agency 
(AFWA),  upper  air  soundings  and  surface  data  to  derive  and  provide 
met  messages  to  field  artillery  fire  units. 

Purpose/Objective 

The  purpose  of  the  present  report  is  to  document  the  design  of  the 
hardware  and  software  that  handles  the  MMS-P  data  assimilation  and 
communication.  Suggestions  for  improving  the  design  for  faster 
execution  are  discussed.  Means  for  reducing  the  number  and 
complexity  of  the  hardware  and  software  interfaces  are  considered. 
The  design  shown  represents  the  system  as  of  the  January  1998 
demonstration. 


2.0  Three  Versions  of  the  MMS 


2.1  The  Fielded  MMS 

The  MMS  is  currently  fielded  as  a  primarily  a  balloon-based  system. 
Its  sensors  are  the  SMS  and  the  MW12  MARWIN  rawindsonde 
system.  The  SMS  measures  surface  winds,  temperature,  and 
humidity  while  the  rawindsonde  measures  balloon  position, 
temperature,  pressure,  and  humidity  aloft.  The  rawindsonde  data  is 
communicated  by  radio  to  the  MARWIN  system  and  then  to  the 
Lightweight  Computer  Unit  (LCU).  The  SMS  data  goes  directly  to  the 
LCU  where  the  data  is  combined  to  produce  meteorological  messages 
that  are  transmitted  via  the  SINCGARS  radio  system.  Data  flow 
details  are  shown  in  section  4.0  of  this  report. 

2.2  The  MMS-P  as  of  January  1998 

Although  the  MMS-P  was  conceived  as  a  product  improvement  to  the 
MMS,  it  represents  a  radical  redesign  incorporating  the  addition  of 
many  new  sensors  and  greatly  increased  computer-processing  power. 
The  new  sensors  and  systems  of  the  MMS-P  proof-of-concept  system 
are  discussed  in  detail  in  section  3.0  of  this  report.  The  primary 
purposes  of  the  present  report  are  to  describe  the  basic  features  of  the 
proof-of-concept  system  as  of  January  1998  (which  will  be  referred  to 
in  this  report  as  MMS-P98)  and  contrast  them  with  some  suggested 
design  improvements. 

The  MMS-P  of  the  January  1998  experiment  was  designed  to 
minimize  changes  to  the  original  MMS.  This  was  motivated  by  two 
situations: 

1.  the  need  to  interface  with  other  existing  systems  (e.g.,  the 
SINCGARS)  and 

2.  the  idea  of  building  the  system  from  more  or  less  independent 
modules. 

2.3  The  MMS-P  (Revised  Version) 

The  design  described  above  minimized  the  changes  to  the  LCU 
software  but  incorporated  some  major  inefficiencies,  which  are 
described  in  more  detail  in  sections  5.0  and  6.0  of  this  report. 
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These  inefficiencies  resulted  in  extra  hardware  and  inferior  system 
performance.  Consequently,  a  redesign  of  the  system  was 
undertaken.  The  resulting  design  reduces  hardware  requirements 
and  improves  system  performance. 


3.0  MMS-P  Sensors  and  Systems 

This  section  describes  the  MMS-P  system,  with  emphasis  on  the 
common  features  of  the  1998  and  revised  version  (RV)  systems. 

3.1  Design  Concepts 

Development  of  a  proof-of-concept  system  embodying  extensive 
previous  research  was  begun  in  FY  1997.  The  concept  underlying  the 
design  was  the  integration  of  a  suite  of  sensors  and 
information-processing  technologies  to  replace  the  balloon.  The 
principal  technical  barrier  that  was  confronted  was  the  difficulty  of 
integrating  these  diverse  technologies,  each  with  its  own  complex 
hardware  and  software  base,  running  on  computers  under  four 
different  operating  systems.  The  expense  of  rewriting  all  the  software 
and  rebuilding  all  the  hardware  to  run  on  a  common  platform  would 
have  been  enormous.  In  addition,  most  of  the  subsystems  were 
commercial  off-the-shelf  systems,  much  of  the  underlying  software 
was  proprietary.  The  approach  adopted  was  a  novel  adaptation  of 
state-of-the-art  techniques  of  software  reusability,  networking,  and 
the  JAVA  programming  language.  [3,4] 

The  MMS-P  system  concept  links  major  components  by  Ethernet  and 
uses  JAVA  to  interface  with  individual  components  and  manage 
overall  system  functions.  The  objective  was  the  design  of  hardware 
and  software  that  would  permit  data  to  captured  from  several  sensors 
without  redesign  of  the  individual  sensor  subsystems.  Because 
networking  protocols  run  on  virtually  all  kinds  of  systems,  and 
because  of  the  portability  and  multi-threading  capabilities  built  into 
JAVA,  the  individual  sensors  can  operate  virtually  independently 
while  the  data  is  being  gathered  and  stored  in  a  database. 

The  top-down,  object-oriented  software  design  gives  an 
unprecedented  degree  of  modularity  to  the  MMS-P's  data  system, 
because  virtually  any  computer-controlled  sensor  can  be  plugged  in 
as  another  object  in  the  sensor  class.  This  design  represents  a 
paradigm  that  can  be  readily  adapted  to  a  wide  variety  of  problems 
where  diverse  sensors  or  other  devices  need  to  be  connected 
and  cooperating. 
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Sensors  and  Subsystems 

The  MMS-P  makes  use  of  local  instruments,  a  local  meteorological 
model,  information  communicated  from  remote  instruments,  and 
information  from  large  scale  models.  The  soundings  it  produces  are 
communicated  by  SINCGARS  radio. 

The  SMS,  a  component  of  the  standard  MMS,  measures  surface  wind, 
temperature,  pressure,  and  humidity.  Its  output  is  processed  by  the 
LCU  computer  and  is  used  by  the  MARWIN  as  well  as  providing 
surface  meteorology  for  the  MMS-P. 

The  primary  upper-air  wind  sensor  is  the  924  MHz,  phased-array 
Doppler  radar.  The  relative  phases  of  the  transmitting  elements  can 
be  varied  to  transmit  in  each  of  five  directions.  The  signal  scattered 
from  atmospheric  refractive  index  discontinuities  is  Doppler  shifted 
in  proportion  to  the  radial  component  of  the  velocity  of  the  scattering 
components  of  the  atmosphere  and  that  Doppler  shift  is  measured  in 
a  range-gated,  heterodyne  detection  scheme.  Vertical  and  horizontal 
winds  are  inferred  from  combinations  of  the  radial  velocities  in  the 
various  directions  (see,  e.g.,  reference  3,  p.  816).  The  range  gating  of 
the  returns  results  in  a  vertical  profile  of  the  wind  velocities  from 
about  100  m  above  the  surface  to  the  height  at  which  the  radar  runs 
out  of  signal-to-noise  ratio,  typically  about  4  to  7  km  above  the 
surface.  A  dedicated  radar  computer  processes  the  radar  data.  [3,  p. 
816] 

The  primary  sensor  of  upper-air  temperature,  humidity,  and  liquid 
water  is  the  microwave  radiometer.  The  radiometer  is  a  passive 
instrument  that  measures  the  natural  microwave  emissions  of 
atmospheric  oxygen,  water  vapor,  and  liquid  water.  Its  retrievals  are 
most  accurate  in  the  lowest  6  km  of  the  atmosphere. 

The  MARWIN  is  the  rawindsonde  system  used  by  the  MMS. 

The  Seaspace  satellite  receiver  system  receives  data  for  the  polar 
orbiting  meteorological  satellites  and  can  process  the  data  to  produce 
wind  and  temperature  fields,  as  well  as  visual  and  infrared  imagery. 

The  SINCGARS  radio  is  the  tactical  communication  link  for  the  MMS 
and  the  MMS-P. 


The  BFM  gives  the  MMS-P  the  capability  to  produce  nowcasts  and 
forecasts  of  the  meteorological  conditions  along  the  trajectory,  in  the 
target  areas,  or  anywhere  else  within  500-km  square. 

The  DirecPC  is  a  specialized  satellite  network  system  that  permits 
global  model  data  to  be  downloaded  for  use  by  the  BFM.  It  is  a 
receive-only  system. 


3.3  Hardware  Interconnection  Design 

The  backbone  of  the  system  is  the  local  area  network  (LAN).  There 
are  five  computers  connected  by  the  LAN: 

•  one  SEASPACE  Sun  SPARC  20, 

•  three  Pentium  PCs,  and 

•  one  486  PC. 

A  sixth  computer,  the  Army  LCU  was  not  connected  to  the  LAN 
during  the  January  1998  experiment.  These  six  computers  make  use 
of  four  different  operating  systems:  Solaris  UNIX,  Santa  Cruz 
Operation  (SCO)  UNIX,  Microsoft  Windows  NT,  and  Microsoft 
Windows  95.  Listed  below  are  these  six  computers,  their  processors, 
operating  systems,  and  principal  functions.  The  Computer  Assisted 
Artillery  Meteorology  (CAAM)/BFM  computer  serves  as  a  surrogate 
LCU,  and  only  one  of  these  is  on  the  system  at  a  time  in  the 
configurations  discussed  below. 


Computer 

Processor 

Operating 

system 

Principal  functions 

Sun 

SPARC  20 

Solaris  UNIX 

Satellite  data  receiver  and 
processor 

Radar  computer 

Pentium 

Windows  NT 
Workstation 

Radar  control  and  data 
acquisition 

MPS  Main 

Pentium 

Windows  NT 
Server 

Main,  data  base,  serial 
instrument  controller 

CAAM/BFM 

Pentium 

SCO  UNIX 

Run  BFM,  create  CAAM 
messages 

DirecPC 

486 

Windows  95 

Receive  data  from  IMETS  and 
NOGAPS 

LCU 

Pentium 

SCO  UNIX 

Control  MARWIN  and 
SINCGARS 

Note: 

MPS  Mobile  Profiler  System 
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On  the  MPS  Main  (Windows  NT  Server)  system,  an  eight-port 
module  is  used  to  ingest  the  data  from  the  SMS,  MARWIN,  and  the 
radiometer.  Two  ports  are  required  for  each  sensor.  On  the  LCU 
system,  another  eight-port  module  is  used  to  ingest  the  data  from  the 
SMS,  MARWIN,  and  to  have  access  to  a  printer.  This  made  for  10 
serial  ports  between  the  NT  and  the  SCO  systems.  This  design 
allowed  the  data  stream  from  the  SMS  and  MARWIN  to  be  captured 
in  the  NT  system  with  a  minimum  of  changes  to  the  MMS  software. 

Figure  1  shows  the  layout  of  systems  in  the  January  1998 
demonstration.  In  the  diagram,  computers,  instruments,  and 
peripherals  are  represented  by  large  rectangles.  Lines  ending  in 
smaller,  darker  shaded  rectangles  attached  to  the  computers  represent 
the  LAN,  and  lines  ending  in  arrows  represent  serial  connections. 
The  zigzag  lines  represent  radio  communication  via  SINCGARS.  The 
dark  blue  line  shows  data  flow  from  the  SMS  to  MPS  Main  while  the 
green  line  shows  it  echoed  to  the  LCU.  Similarly,  the  sky  blue  line 
shows  data  flow  from  the  MARWIN  to  the  MPS  Main  and  the  pink 
line  shows  the  MARWIN  data  being  echoed  to  the  LCU. 


Figure  1.  MMS-P  hardware  interconnection,  January  1998  demonstration. 


Note  that  the  LCU  is  not  connected  to  the  LAN  in  the  January  1998 
configuration. 


4.0  Data  Flow  in  the  MMS 


Figure  2  shows  the  data  flow  in  the  MMS.  Note  that  five  serial 
connections  are  involved: 


•  one  with  the  SMS, 

•  one  with  the  printer, 

•  three  with  the  MARWIN. 

The  connection  shown  from  the  Tactical  Communications  Interface 
Module  (TCIM)  to  connect  to  the  SINCGARS  is  a  Small  Computer 
System  Interface  (SCSI).  One  of  the  serial  ports  used  is  native  to  the 
LCU  and  the  other  four  pass  through  the  Digi  8,  8-serial  port  board. 
This  figure  will  serve  as  a  baseline  for  the  discussion  of  the  MMS-P98 
and  MMS-P  (RV)  below.  The  Digi  8  boards  and  the  software  to 
control  them  are  described  in  an  ARL  report.  [7] 


Figure  2.  MMS 
hardware 

connection  diagram. 


SMS  =  SEMI-AUTOMATIC  MET  STATION 

MARWIN  requires  3  serial  ports 

1.  S2  for  10  sec  data 

2.  S5  receives  Surface  Sensor  readings. 

3.  SI  communications  with  LCU 
Met  Messages 


SMS  /dev/ttyi  1  d  or  /dev/ttya03 
MARWIN  SI  /dev/tty2a 
MARWIN  S2  /dev/ttyi  1  c  or  /dev/ttya02 
MARWIN  S5  /dev/ttyi lb  or/dev/ttyaOl 
PRINTER  /dev/ttyi  1  a  or  /dev/ttyaOO 


The  eight-port  module  attached  to  the  LCU  was  added  to  the  original 
MMS  under  a  Value  Engineering  Change  Proposal  (VECP)  and  was 
used  for  communication  with  the  MARWIN  and  the  LCU  printer.  In 
addition  to  the  output  communication,  s2  shown  in  figure  2  for  the 
MARWIN,  s5  is  an  input  to  the  MARWIN,  and  the  LCU  also  conducts 
a  bi-directional  communication  with  the  MARWIN  through  one  of  its 
native  serial  ports.  The  fourth  eight-port  module  serial  port  connects 
the  LCU  to  a  printer. 
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5.0  Data  Flow  in  MMS-P98 

In  addition  to  system  connectivity,  figure  1  (section  3.0)  shows  the 
paths  of  data  flow  in  the  MMS-P.  The  dotted  line  is  drawn  around 
the  original  MMS  components.  Comparison  of  figures  1  and  2  will 
show  that  the  original  MMS  core  looks  almost  unchanged.  The  major 
difference  is  that  two  data  paths  that  go  directly  from  instruments  to 
the  LCU  in  figure  2,  go  (figure  1)  into  the  smart  board  of  MPS-main 
computer.  Two  corresponding  data  paths  also  go  (figure  1)  from  the 
MPS-main  smartboard  to  the  LCU  smartboard. 

The  purpose  of  these  changes  was  to  make  the  original  design  of  the 
MMS-P  minimally  impact  the  MMS  software.  Because  the  SMS  and 
MARWIN  rawindsonde  observation  (raob)  data  were  needed  by  both 
the  LCU  and  the  MMS-P,  a  design  was  adopted  in  which  the  output 
of  the  SMS  and  MARWIN  were  captured  by  MPS  Main  via  ports  3 
and  5  of  the  attached  eight-port  module.  These  signals  were  echoed 
to  the  LCU  via  ports  4  and  6  of  the  MPS  Main  eight-port  board  and 
thence  to  the  p3  and  p4  ports  of  the  smart  board  attached  to  the  LCU. 

Figure  3  shows  the  connections  between  the  eight  port  boards  in 
more  detail. 


Figure  3.  Connections  of  the  eight-port  boards  in  the  MMS-P98. 
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This  design  produced  minimal  changes  in  the  configuration  of  the 
original  portion  of  the  MMS  but  did  so  at  a  cost  in  efficiency. 
Software  and  system  processing  time  were  needed  to  process  and 
echo  the  incoming  signals,  and  delays  were  introduced.  In  addition, 
six  ports  were  required  to  handle  the  signals  that  had  formerly 
required  only  two. 

The  sensors  and  peripherals  are  connected  to  the  system  by  serial 
connections  to  the  two  eight-port  smart  board  modules.  Each  smart 
board  has  an  onboard  buffer  and  controls  eight  serial  ports.  A 
detailed  interconnection  for  the  two  eight-port  modules  is  shown  in 
figure  3.  In  the  figure,  the  large  rectangle  in  the  center  represents  the 
eight-port  module  attached  to  the  MPS  main  computer;  the  smaller 
rectangle  at  the  lower  left  represents  the  same  on  the  LCU  (only  four 
of  the  eight  ports  are  shown). 

The  MPS  main  computer  can  run  simulators  for  the  SMS  surface 
sensor  and  the  MARWIN  balloon  system.  When  the  system  is  run  in 
that  mode,  the  simulated  MARWIN  output  is  sent  from  COM  7  to 
COM  5  in  place  of  the  actual  MARWIN  s2  output.  Similarly, 
simulated  SMS  output  is  sent  from  an  MPS  native  serial  port  to 
COM  3.  The  real  or  simulated  MARWIN  data  coming  in  on  COM  5  is 
sent  out  to  the  LCU  via  COM  6  (of  the  MPS  smart  board)  and  p3  (of 
the  corresponding  LCU  module).  Similarly,  SMS  data  gets  to  the  LCU 
via  COM  4  and  p4. 

Surface  Sensor 

Data  flow  from  the  SMS  AN/TMQ-50  (surface  sensor)  and 
supporting  software  is  diagrammed  in  figure  4. 


sms  in  SMS  (Surface  Sensor)  Data  Flow 


Figure  4.  SMS  data  flow  in  MMS-P98. 

In  a  conventional  MMS,  SMS  data  would  flow  directly  from  the 
sensor  to  p4  of  the  LCU,  but  in  the  MMS-P98,  the  SMS  data  is  first 
intercepted  and  stored  in  two  forms  on  the  MPS  computer.  In  the 
figure,  the  three  rectangular  boxes  below  the  eight-port  module 
rectangle  represent  the  software  interface  with  the  MPS  main 
computer.  From  top  to  bottom,  they  are  respectively,  the  Digi  eight- 
port  board,  low-level  interface;  the  Windows  NT  ( CommPort.dll ) 
interface;  and  the  JAVA  ( CommPort.class )  interface.  The  ovals  below 
represent  JAVA  objects. 

The  SMS.class  program  instantiates  the  SurfSen.class  program,  which 
is  the  central  communication  node  for  the  SMS  sensor,  receiving  data 
from  and  sending  data  to  the  eight-port  module,  sending  data  via  the 
toC. class  to  a  C  program  that  stores  data  to  the  sen.txt  file.  It  also 
receives  location  data,  derived  ultimately  from  the  Global  Positioning 
System  (GPS). 
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The  combined  data  is  time  stamped  and  sent  to  be  stored  in  the 
Microsoft  Standard  Query  Language  (MSSQL)  database.  The  data 
sent  back  to  the  eight-port  module  goes  to  the  LCU,  and  then  to  the 
MMS  SCO  Unix  system,  where  it  is  processed  (wind  direction 
converted  from  mills  to  degrees  and  wind  speed  converted  to  meters 
per  second)  and  output  on  /dev/ttyilb  for  input  to  the  MARWIN. 
The  LCU  supplies  data  to  the  MARWIN  processor  and  uses  the  data 
in  an  extrapolation  model  that  in  turn  produces  a  nine  line  met 
message  from  surface  observations.  A  UNIX  pipe  of  the  surface  data 
is  located  in  / usr /RUN /surf sin. 

5.2  MARWIN  Data  Flow 

An  analogous  data  flow  diagram  for  the  MARWIN  data  flow  is  given 
below  in  figure  5.  Note  the  strong  structural  similarities  in  the 
software  design,  a  feature  of  the  object  oriented  modular  design. 


The  design  (January  1998)  calls  for  five  serial  ports  on  the  LCU — the 
SMS  and  MARWIN  data  from  MPS  Main,  the  two-way  channel  SI  to 


the  MARWIN,  S5  to  the  MARWIN,  and  output  to  a  serial  printer. 


Figure  5.  MARWIN  data  flow  in  MMS-P98. 
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5.3  Radiometer  Data  Flow  in  the  MMS-98 

The  final  system  directly  affected  by  the  proposed  revisions  is  the 
radiometer.  Figure  6  below  shows  the  software  outline  for  the 
radiometer  in  the  1998  configuration.  The  drastically  different 
structure  compared  with  figures  4  and  5  reflects  the  difficulties 
inherent  in  incorporating  its  software,  which  was  written  as  a  stand¬ 
alone  disk  operating  system  (DOS)  program,  into  the  modular 
architecture. 


Radiometer 

WVR  in 

Radiometer  Data  Flow 

Radiometer 

TP  in 

COM9 

COM  10 

Eight  Port  Module 

Digi  PC/8e 

Digi  Low  level  Driver 


J 

COMMS.LIB 

SERIAL. C 

I  > 

COMMPORT.C  | 

1 - 1  1 

WVR5.FOR 

MAIN.FOR  ■  ->[ 

KEY.H  <  >|  KEY.FOR  \-* 

.  &+.FOR 

- V — — 

Keyboard 


DEFAULT.LOS 
DEFAULT.SAV 
DEFAULT. ERR 
DEFAULT.LOG 
COMMS.LOG 


Figure  6.  Radiometer  data  flow  in  the  MMS-98. 
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6.0  Connections  and  Data  Flow  in  the  MMS-P  (RV) 

The  design  shown  in  figure  1  minimized  the  changes  to  the  LCU 
software  but  incorporated  two  major  inefficiencies — the  delay  and 
additional  ports  entailed  by  the  shuffling  of  the  data  first  into  MPS 
Main  and  then  to  the  LCU.  An  even  more  important  problem  is 
connectivity  with  the  LCU,  which  lacks  the  capability  to  connect  to 
the  LAN. 

The  rationale  for  this  design  was  that  the  MMS-P  required  the  data 
provided  by  the  SMS  and  this  design  minimized  the  changes  to  be 
made  since  the  MMS-P  was  simply  placed  in  the  data  flow  of  the  SMS 
to  the  MMS.  It  was  already  planned  that  the  LCU  software  would  be 
transported  to  another  SCO  UNIX  computer  with  room  for  a  LAN 
card.  This  was  not  implemented  in  the  January  1998  configuration 
though,  because  we  had  not  yet  been  able  to  solve  the  problem  of 
integrating  the  TCIM  (connecting  the  computer  to  the  SINCGARS)  on 
the  computer. 

Since  then,  a  more  detailed  understanding  of  the  LCU  code  has 
revealed  important  potential  improvements.  The  TCIM  problem  was 
solved,  and  the  LCU  code  was  transported  to  a  more  flexible 
computer.  In  addition,  it  was  learned  that  the  MARWIN  and  SMS 
data  go  to  UNIX  data  pipes.  Consequently,  it  is  simple  to  put  UNIX 
Tees  in  the  pipes  to  send  the  data  to  one  or  more  other  locations. 


These  facts  make  possible  the  following  revised  design,  shown  in 
figure  7  below. 


Figure  7.  MMS-P  (RV)  system  connectivity. 
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The  design  includes  a  LAN  connection  to  the  LCU  replacement 
(shown  as  the  heavy  black  line)  and  now  provides  full  connectivity  of 
all  MMS-P  systems,  which  is  essential  for  an  automated  system.  The 
design  in  figure  7  also  simplifies  and  speeds  up  the  data  transfer  from 
the  SMS  and  MARWIN.  Four  serial  ports  are  eliminated,  see  specific 
sections  devoted  to  the  MARWIN  and  SMS  below. 

The  remaining  design  issue  concerns  how  the  data  should  be  shared 
among  the  computers.  Options  considered  included  sockets, 
hypertext  transfer  protocol  (HTTP),  and  the  SAMBA  file  system.  The 
SAMBA  file  system  permits  a  UNIX  system  to  share  a  disk  drive  with 
Windows  systems.  The  SAMBA  system,  running  on  the  LCU,  was 
adopted  because  it  provided  a  good  mix  of  simplicity  and  flexibility. 


6.1  SMS  and  MARWIN  Data  Flow  in  the  MMS-P  (RV) 

The  new  system  design  used  with  SAMBA  frees  COM3  and  COM4  on 
the  MMS-P  system.  Figure  8  shows  the  data  flow  of  the  SMS  and 
MARWIN  data  into  the  SCO  system  where  the  processing  takes  place 
and  the  data  is  output  to  MARWIN  s5  on  /dev/ttyilb  or 
/dev/ttyaOl.  The  lower  half  of  figure  8  shows  the  software  changes 
required.  By  comparing  figures  4  and  5  with  8,  the  resulting  design  is 
cleaner  and  provides  an  improvement  in  the  SMS  data  flow. 


Figure  8.  SMS  and  MARWIN  data  flow  into  SCO  UNIX  computer. 


The  hardware  changes  shown  above  require  corresponding  changes 
in  the  software.  Because  of  the  modularity  of  the  system  design,  these 
changes  are  not  great.  For  example,  in  figure  4,  SMS  data  is  received 
on  COM3  by  the  MPS  main  (NT)  computer  and  retransmitted  to  the 
LCU  via  COM4.  In  the  revised  design,  this  data  is  received  by  MPS 
Main  via  LAN  from  the  LCU  by  means  of  a  socket. 

This  requires  code  changes  on  both  computers.  The  required  C  code 
for  the  LCU  (Clientun.c)  runs  only  103  lines  and  is  listed  in 
appendix  A.  The  corresponding  code  for  MPS  Main  is  a  modified 
version  of  the  JAVA  code  used  in  the  MMS-P98  to  forward  the  SMS 
data  to  the  LCU.  It  has  been  modified  from  sending  a  file  to  receiving 
it.  This  code,  Server.JAVA,  is  only  59  lines,  and  is  listed  in 
appendix  B. 

The  situation  with  MARWIN  data  flow  is  very  similar.  The  principal 
change  on  MPS  Main  is  the  replacement  of  the  COM5  data  flow  with 
communication  using  a  socket.  The  required  software  is  very  similar 
to  that  used  for  the  SMS  data.  On  the  LCU  side,  the  MARWIN  data 
flow  is  shown  in  more  detail  below  in  figure  9. 


Figure  9.  Data  Flow  from  MARWIN  to  SCO  UNIX  computer. 
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The  code  required  to  send  the  data  via  LAN  from  the  LCU  to  MPS 
Main  is  very  similar  to  that  used  for  the  SMS  data. 

Radiometer  Data  Flow  in  the  MMS-P  (RV) 

In  the  MMS-P98  design,  the  radiometer  uses  the  eight-port  module 
(Digi  PC/8e)  on  the  MPS  WIN  NT  4.0  Server  (figure  6).  The 
radiometer  is  physically  connected  to  COM9  and  COMIO  on  the 
Digi  PC  /8e.  The  rationale  for  this  design  was  that  the  radiometer 
software  will  runs  on  the  MPS  WIN  NT  4.0  Server. 

The  RV  design  exploits  the  fact  that  this  is  not  required.  The 
radiometer  can  be  physically  connected  elsewhere  (figure  10)  and 
communicate  with  the  software  on  the  MPS  WIN  NT  4.0  over  a  pair  of 
network  sockets.  Since  it  is  being  proposed  that  the  MARWIN  and 
surface  sensor  be  connected  physically  to  the  LCU  Pentium  90,  the 
new  design  does  the  same  for  the  radiometer.  This  move  would 
eliminate  the  need  for  the  Digi  PC/8e  on  the  MPS  Main  computer. 
This  would  eliminate  a  large  number  of  cables  and  improve  the 
data  flow. 


As  was  the  case  with  SMS  and  MARWIN,  only  minor  changes  to  the 
software  are  necessary  to  implement  this  change.  Figure  10  shows  the 
proposed  changes  to  the  radiometer  data  flow. 


Figure  10.  Radiometer  data  flow,  proposed  changes. 


7.0  Combined  LCU  and  CAAM/BFM  Functions 

In  addition  to  the  changes  in  port  connections  between  figures  1 
and  7,  the  other  major  change  is  lumping  together  in  figure  7  of  the 
CAAM/BFM  and  LCU  computers.  This  reflects  the  system  redesign 
to  combine  the  functions  of  the  LCU  and  the  CAAM/BFM  computers 
in  a  single  system.  This  was  necessary  because  the  LCU  lacked  the 
capability  to  connect  to  the  LAN.  An  additional  crucial  benefit  was 
the  reduction  in  the  total  number  of  computers  required  by  one. 
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8.0  Remaining  Issues 

8.1  Connections  and  Interfaces 

The  elimination  of  the  eight-port  module  from  the  MPS  main 

computer  leaves  some  unresolved  issues,  outlined  below: 

•  The  si  connection  between  the  MARWIN  and  the  LCU  is  used  to 
transfer  the  met  messages  to  the  LCU  and  for  status  information 
from  the  LCU  to  the  MARWIN.  The  absence  of  this  handshaking, 
which  is  not  yet  implemented  on  the  LCU  replacement,  causes  an 
alert  on  the  MARWIN. 

•  The  status  of  the  LCU  replacement's  interface  to  the  TCIM  is  still 
undetermined.  The  TCIM  is  the  interface  to  the  SINCGARS 
(radio)  that  transmits  to  and  receives  messages  from  other  fire 
control  systems. 

•  In  the  MMS,  the  s2  port  of  the  eight-port  module  is  used  to  print 
raob  status  and  data  during  a  flight.  The  status  of  this  connection 
in  the  replacement  LCU  is  not  yet  determined. 


The  dotted  lines  in  figure  11  indicate  the  locations  of  the  unresolved 
connections. 
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Data  Transfer  from  SEASPACE  Satellite  System 

Currently,  the  SEASPACE  is  using  a  file  transfer  protocol  (FTP) 
method  of  transferring  its  data  to  the  MMS-P.  A  method  employing 
client/server  sockets,  like  that  used  for  radiometer,  SMS,  and 
MARWIN  data  is  preferable  for  the  SEASPACE  also. 


9.0  Conclusions 


The  lessons  learned  from  operation  of  the  system  in  the  January  test 
and  subsequent  analysis,  resulted  in  a  new  design  presented  in  this 
report.  The  new  design  reduces  the  hardware  and  simplifies  of 
software  interfaces.  With  the  new  design,  the  processes  will  run 
faster  and  will  not  interfere  with  the  operation  in  the  MMS  mode,  as 
was  the  case  in  the  original  design. 
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Acronyms 


AFWA 

Air  Force  Weather  Agency 

ARL 

Army  Research  Laboratory 

BED 

Battlefield  Environment  Division 

BFM 

Battlescale  Forecast  Model 

CAAM/BFM 

Computer  Assisted  Artillery  Meteorology/ 

Battlescale  Forecast  Model 

CISD 

Computational  Information  Sciences  Directorate 

DOS 

Disc  Operating  System 

FTP 

File  Transfer  Protocol 

GPS 

Global  Positioning  System 

HTTP 

Hypertext  Transfer  Protocol 

LAN 

local  area  network 

LCU 

Army  Lightweight  Computer  Unit 

MMS 

Met  Measuring  Set 

MMS-P  (RV) 

MMS  Profiler  (proof-of-concept  system,  revised 
version) 

MMS-P 

MMS  Profiler  (proof-of-concept  system) 

MMS-P98 

MMS  Profiler  (proof-of-concept  system,  version  used 
in  January  1998  test) 

MPS 

Mobile  Profiler  System 

MSSQL 

Microsoft  Standard  Query  Language 

NOGAPS 

Navy  Operational  Global  Atmospheric  Prediction 
System 

raob 

rawindsonde  observation 

SCO 

Santa  Cruz  Operation 

SCSI 

Small  Computer  System  Interface 
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SINCGARS 

SMS 

TCIM 


Single  Channel  Ground  and  Airborne  Radio  System 
Semi-automatic  Meteorological  Station 
Tactical  Communications  Interface  Module 
Value  Engineering  Change  Proposal 


VECP 


Appendix  A 
Clientun.c 


#include  <sys/types.h> 

#include  <sys/  socket. h> 

#include  <netinet/in.h> 

#include  <netdb.h> 

#include  <stdio.h> 
char DATA[1000]; 

/*#define  DATA  "sending  data"*/ 
readmessg() 

{ 

FILE  *pt2; 
int  i; 

char  inputch; 
i=0; 

pt2=fopen("3230681.met","r"); 

while(fscanf(pt2,"%c",&inputch)  !=  EOF) 

{ 

DATA[i]=inputch; 

/*printf("%c"/DATA[i]);*/ 

i++; 

} 

/*printf("\ni=%d\n",i);*/ 

i++; 

DATA[i]=0; 

fclose(pt2); 


/*  This  program  creates  a  socket  */ 

main(argc,  argv) 
int  argc; 
char  *argv[]; 

{ 

int  sdata; 
char  *adddata; 
int  sock; 

struct  sockaddr_in  server; 
struct  hostent  *hp,  *gethostbyname(); 
char  buf[1024]; 
int  rval; 
readmessgQ; 


/*  Create  Socket  */ 


sock  =  socket  (  AFJNET,  SOCK_STREAM,  0); 
if  (  sock  ==  -1 ) 

{ 

perror(  "opening  stream  socket" ); 
exit(l); 

} 

/*  Connect  socket  using  name  specified  by  command  line  */ 

server  .sin_family  =  AF_INET; 
hp  =  gethostbyname(  argv[l] ); 
printf("hostname  =  %s\n",  hp->h_name); 
printf("host_address_type  =  %d\n",  hp->h_addrtype); 
printf("h_length  =  %d\n",  hp->h_length); 
printf("host_address  =  %d\n",  hp->h_addr); 

pr_inet(hp->h_addr_list,  hp->h_length); 

/*  gethostbyname  returns  a  structure  including  the  network  address  of  the 
specified  host  */ 

if  ( (hp  ==  (struct  hostent  *)  0 )) 

{ 

fprintf(  stderr,  "%s:  unknown  host\n",  argv[l] ); 
exit(2); 

} 

memcpy(  (char  *)  &server.sin_addr,  (char  *)  hp->h_addr,  hp->h_length ); 
server.sin_port  =  htons(  atoi(  argv[2] )); 

if  (  connect(  sock,  (struct  sockaddr  *)  &server,  sizeof  server )  ==  -1 ) 

{ 

perror(  "connecting  stream  socket"); 
exit(l); 

} 

adddata=  &DATA; 
sdata=sizeof  DATA; 

/*  printf("%x  “/odXn'^adddata^data);*/ 
if  ( write(  sock,  adddata,  sdata)  ==  -1 ) 

perror(  "writing  on  stream  socket" ); 


if  ( read(  sock,  buf,  sizeof  buf )  ==  -1 ) 

perror(  "reading  stream  socket" ); 

printf("%s\n",  buf); 
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close(  sock ); 
exit(O); 

} 

pr_inet(listptr,  length) 
char  **listptr; 
int  length; 

{ 

struct  in_addr  *ptr; 

while  ( (ptr  =  (struct  in_addr  *)  *listptr++)  !=  NULL) 
printf("\nlntemet  address:  %s\n\n",  inet_ntoa(*ptr)) 

} 


Appendix  B 
ServerList.java 


/* 

#  SHeader: 

\  \  \  \EAGLE053\  \default\  \RCS\  \K\  \java\  \src\  \socket\  \ServerList.java,v  1 
1998/02/03  19:42:52  administrator  Exp  administrator  $ 

V 

import  java. net.*; 
import  java.io.*; 
import  java.lang.*; 

public  class  ServerList 

{ 

static  RandomAccessFile  in; 

public  ServerList(int  port)  throws  java.io.IOException 

{ 

ServerSocket  ss=new  ServerSocket(port,l); 
System.out.println("started"); 

/* 

System.out.println("Accepting  connections  on  local  machine  "  + 
ss.getInetAddress().toString()  +  "  on  local  port " 

+  ss.getLocalPortQ  + 

V 

Socket  conSock; 

InputStream  sockinp; 
byte  b[]=new  byte[1024]; 

conSock=ss .  accept(); 
sockinp=conSock.getInputStream(); 
int  bread; 

/* 

System.out.println("Connected  to  remote  machine  at "  + 
conSock.getInetAddress().toString()  + 

"  on  remote  port "  +  conSock.getPort()  + 

"  using  local  port "  +  conSock.getLocalPort()  + 

V 

while(sockinp.available()  >  0 ) 


System.out.print((char)sockinp.read()); 

} 


in.closeQ; 


public  static  void  main(String  a[])  throws  java.io.IOException 

{ 

if(a.length  <  2) 

{ 

System.out.println("Usage:  ServerList  <port>  <filename>"); 
return; 


in-new  RandomAccessFile(a[l],"r"); 

ServerList  ser=new  ServerList(!nteger.parseInt(a[0])); 


NASA  MARSHALL  SPACE  FLT  CTR 
ATMOSPHERIC  SCIENCES  DIV 
E501 

ATTN  DR  FICHTL 
HUNTSVILLE  AL  35802 

NASA  SPACE  FLT  CTR 
ATMOSPHERIC  SCIENCES  DIV 
CODE  ED  41  1 
HUNTSVILLE  AL  35812 

US  ARMY  MISSILE  CMND 
AMSMI  RD  AC  AD 
ATTN  DR  PETERSON 
REDSTONE  ARSENAL  AL  35898-5242 

US  ARMY  MISSILE  CMND 
AMSMI  RD  AS  SS 
ATTN  MR  H  F  ANDERSON 
REDSTONE  ARSENAL  AL  35898-5253 

US  ARMY  MISSILE  CMND 
AMSMI  RD  AS  SS 
ATTN  MR  B  WILLIAMS 
REDSTONE  ARSENAL  AL  35898-5253 

US  ARMY  MISSILE  CMND 
AMSMI  RD  DE  SE 
ATTN  MR  GORDON  LILL  JR 
REDSTONE  ARSENAL  AL  35898-5245 

US  ARMY  MISSILE  CMND 
REDSTONE  SCI  INFO  CTR 
AMSMI  RD  CS  R  DOC 
REDSTONE  ARSENAL  AL  35898-5241 

US  ARMY  MISSILE  CMND 
AMSMI 

REDSTONE  ARSENAL  AL  35898-5253 

PACIFIC  MISSILE  TEST  CTR 
GEOPHYSICS  DIV 
ATTN  CODE  3250 
POINT  MUGU  CA  93042-5000 

ATMOSPHERIC  PROPAGATION  BRANCH 
SPAWARSYSCEN  SAN  DIEGO  D858 
49170  PROPAGATION  PATH 
SAN  DIEGO  CA  92152-7385 

METEOROLOGIST  IN  CHARGE 
KWAJALEIN  MISSILE  RANGE 
PO  BOX  67 

APO  SAN  FRANCISCO  CA  96555 


NCAR  LIBRARY  SERIALS 
NATL  CTR  FOR  ATMOS  RSCH 
PO  BOX  3000 
BOULDER  CO  80307-3000 

HEADQUARTERS  DEPT  OF  ARMY 
DAMI  POI 
ATTN  LEE  PAGE 
WASHINGTON  DC  20310-1067 

MIL  ASST  FOR  ENV  SCI  OFC 
OF  THE  UNDERSEC  OF  DEFNS 
FOR  RSCH  &  ENGR  R&AT  E  LS 
PENTAGON  ROOM  3D129 
WASHINGTON  DC  20301-3080 

DEAN  RMD 
ATTN  DR  GOMEZ 
WASHINGTON  DC  20314 

US  ARMY  INFANTRY 
ATSH  CD  CS  OR 
ATTN  DR  E  DUTOIT 
FT  BENNING  GA  30905-5090 

HQ  AFWA/DNX 

106  PEACEKEEPER  DR  STE  2N3 

OFFUTT  AFB  NE  68113-4039 

PHILLIPS  LABORATORY 
PL  LYP 

ATTN  MR  CHISHOLM 
HANSCOM  AFB  MA  01731-5000 

PHILLIPS  LABORATORY 
PL  LYP  3 

HANSCOM  AFB  MA  01731-5000 

AFRL/VSBL 
29  RANDOLPH  RD 
HANSCOM  AFB  MA  01731 

ARL  CHEMICAL  BIOLOGY 
NUC  EFFECTS  DIV 
AMSRL  SL  CO 
APG  MD  21010-5423 

US  ARMY  MATERIEL  SYST 
ANALYSIS  ACTIVITY 
AMSXY 

APG  MD  21005-5071 

ARMY  RESEARCH  LABORATORY 
AMSRL  D 

2800  POWDER  MILL  ROAD 
ADELPHI  MD  20783-1145 
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ARMY  RESEARCH  LABORATORY 
AMSRL  OP  Cl  SD  TL 
2800  POWDER  MILL  ROAD 
ADELPHI  MD  20783-1145 

ARMY  RESEARCH  LABORATORY 
AMSRL  Cl  LL 
ADELPHI  MD  20703-1197 

ARMY  RESEARCH  LABORATORY 
AMSRL  SS  SH 
ATTN  DR  SZTANKAY 
2800  POWDER  MILL  ROAD 
ADELPHI  MD  20783-1145 

ARMY  RESEARCH  LABORATORY 
AMSRL  Cl 
ATTN  J  GANTT 
2800  POWDER  MILL  ROAD 
ADELPHI  MD  20783-1197 

ARMY  RESEARCH  LABORATORY 
AMSRL 

2800  POWDER  MILL  ROAD 
ADELPHI  MD  20783-1145 

NATIONAL  SECURITY  AGCY  W21 
ATTN  DR  LONGBOTHUM 
9800  SAVAGE  ROAD 
FT  GEORGE  G  MEADE  MD  20755-6000 

US  ARMY  RSRC  OFC 
ATTN  AMXRO  GS  DR  BACH 
PO  BOX  12211 
RTP  NC  27009 

DR  JERRY  DAVIS 
NCSU 

PO  BOX  8208 
RALEIGH  NC  27650-8208 

US  ARMY  CECRL 
CECRL  GP 
ATTN  DR  DETSCH 
HANOVER  NH  03755-1290 

US  ARMY  ARDEC 
SMC AR IMI I  BLDG  59 
DOVER  NJ  07806-5000 

ARMY  DUGWAY  PROVING  GRD 
STEDP  MT  DA  L  3 
DUGWAY  UT  84022-5000 

ARMY  DUGWAY  PROVING  GRD 
STEDP  MT  M 
ATTN  MR  BOWERS 
DUGWAY  UT  84022-5000 


DEPT  OF  THE  AIR  FORCE  1 

OL  A  2D  WEATHER  SQUAD  MAC 
HOLLOMAN  AFB  NM  88330-5000 

PL  WE  1 

KIRTLAND  AFB  NM  87118-6008 

USAF  ROME  LAB  TECH  1 

CORRIDOR  W  STE  262  RL  SUL 
26  ELECTR  PKWY  BLD  106 
GRIFFISS  AFB  NY  13441-4514 

AFMC  DOW  1 

WRIGHT  PATTERSON  AFB  OH  45433-5000 

US  ARMY  FIELD  ARTILLERY  SCHOOL  1 

ATSF  TSM  TA 
FT  SILL  OK  73503-5600 

US  ARMY  FOREIGN  SCI  TECH  CTR  1 

CM 

220  7TH  STREET  NE 
CHARLOTTESVILLE  VA  22448-5000 

NAVAL  SURFACE  WEAPONS  CTR  1 

CODE  G63 

DAHLGREN  VA  22448-5000 

US  ARMY  OEC  1 


CSTE  EFS 
PARK  CENTER  IV 
4501  FORD  AVE 
ALEXANDRIA  VA  22302-1458 


US  ARMY  CORPS  OF  ENGRS  1 

ENGR  TOPOGRAPHICS  LAB 
ETL  GS  LB 

FT  BELVOIR  VA  22060 

US  ARMY  TOPO  ENGR  CTR  1 

CETEC  ZC  1 

FT  BELVOIR  VA  22060-5546 

SCI  AND  TECHNOLOGY  1 

101  RESEARCH  DRIVE 
HAMPTON  VA  23666-1340 

US  ARMY  NUCLEAR  CML  AGCY  1 

MONA  ZB  BLDG  2073 
SPRINGFIELD  VA  22150-3198 

USATRADOC  1 

ATCD  FA 

FT  MONROE  VA  23651-5170 

ATRC  WSS  R  1 

WSMR  NM  88002-5502 
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ARMY  RESEARCH  LABORATORY 
AMSRL  Cl  E 
COMP  &  INFO  SCI  DIR 
WSMR  NM  88002-5501 

DTIC 

8725  JOHN  J  KINGMAN  RD 
STE  0944 

FT  BELVOIR  VA  22060-6218 

US  ARMY  MISSILE  CMND 
AMSMI 

REDSTONE  ARSENAL  AL  35898-5243 

US  ARMY  DUGWAY  PROVING  GRD 
STEDP3 

DUGWAY  UT  84022-5000 

USTRADOC 
ATCD  FA 

FT  MONROE  VA  23651-5170 

WSMR  TECH  LIBRARY  BR 
STEWS  IM  IT 
WSMR  NM  88002 

US  ARMY  RESEARCH  LAB 
AMSRL  D  DR  D  SMITH 
2800  POWDER  MILL  RD 
ADELPHI  MD  20783-1197 

US  ARMY  CECOM 
INFORMATION  &  INTELLIGENCE 
WARFARE  DIRECTORATE 
ATTN  AMSEL  RD  IW  IP 
FORT  MONMOUTH  NJ  07703-5211 

JAMES  COGAN  BRANCH  CHIEF 
ARMY  RESEARCH  LAB 
AMSRL  IS  EA 
WSMR  NM  88002-5501 

ARMY  RESEARCH  LAB 
AMSRL  IS  EA 
ALFRED  GUTIERREZ 
WSMR  NM  88002-5501 

ARMY  RESEARCH  LAB 
AMSRL  IS  EA 
EDWARD  VIDAL  JR 
WSMR  NM  88002-5501 

ARMY  RESEARCH  LAB 
AMSRL  IS  EA 
EDWARD  MEASURE 
WSMR  NM  88002-5501 
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ARMY  RESEARCH  LAB 
AMSRL  IS  EA 
DAVID  QUINTIS 
WSMR  NM  88002-5501 

ARMY  RESEARCH  LAB 
AMSRL  IS  EA 
GAIL  VAUCHER 
WSMR  NM  88002-5501 


Record  copy  1 

TOTAL  85 
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